home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000091_owner-urn-ietf _Thu Nov 7 09:36:07 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27494 for urn-ietf-out; Thu, 7 Nov 1996 09:36:07 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27489 for <urn-ietf@services.bunyip.com>; Thu, 7 Nov 1996 09:36:05 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA21314  (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 09:36:01 -0500
  5. Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
  6.           id <00725-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 15:33:12 +0100
  7. Subject: Re: [URN] Re meaningful names
  8. To: girod@LCS.MIT.EDU
  9. Date: Thu, 7 Nov 1996 15:33:11 +0100 (MET)
  10. Cc: tallen@fsc.fujitsu.com, urn-ietf@bunyip.com
  11. In-Reply-To: <9611070152.AA06320@skadhwe.lcs.mit.edu> from "Lewis Girod" at Nov 6, 96 08:52:18 pm
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=US-ASCII
  14. Content-Transfer-Encoding: 7bit
  15. Content-Length: 2002
  16. From: Martin J Duerst <mduerst@ifi.unizh.ch>
  17. Message-Id: <"josef.ifi..915:07.10.96.14.33.19"@ifi.unizh.ch>
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Martin J Duerst <mduerst@ifi.unizh.ch>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. Lewis Girod wrote:
  24.  
  25. >   Date: Wed, 6 Nov 1996 16:35:41 -0800 (PST)
  26. >   From: Terry Allen <tallen@fsc.fujitsu.com>
  27.  
  28. >   | Of course, as you point out there is no way to stop people from
  29. >   | putting semantics into names; the most effective way to deal with the
  30. >   | issue is to implement a system of user friendly names over the top of
  31. >   | URNs; 99% of the time the user would see and type only a UFN, and
  32. >   | these UFNs would be resolved to the URNs that could then be used as
  33. >   | long-lived references.
  34. >
  35. >   Twice the work or more, doesn't deal with grandfathering, prone
  36. >   to error; the most effective way to deal with the issue is to
  37. >   drop your objection to meaningful names.
  38. >
  39. >It is more work (though how much more is hard to say), but it might
  40. >prove really useful.  I don't think it would impact grandfathering at
  41. >all; grandfathered names could have a UFN alias or they might just be
  42. >typed in as URNs.  Prone to error?  UFNs wouldn't have the longevity
  43. >characteristics that URNs hopefully would have, if that's what you
  44. >mean -- that's why you don't use them in published links.
  45.  
  46. If you look at what is currently published in terms of URLs,
  47. most of them try to be as user-friendly as possible.
  48. Non-userfriendlyness may be okay for some official publications,
  49. but for publishing things in newspapers and on cardboard boxes,
  50. user-friendliness is on great demand.
  51. Another aspect of user-friendliness is deterministic behaviour
  52. (maybe only shorttime): If you read something in a newspaper,
  53. you want to go to that site/document directly, and not have to
  54. go through search lists, and so on. The side which publishes
  55. a reference likewise wants you to go there directly, and not
  56. be detracted.
  57.  
  58. This may not affect URN internationalization, but it definitely
  59. affects URL internationalization, because for all of the above,
  60. URLs are currently used, with the only restriction that the
  61. advantages the users look for are limited to English plus a
  62. few other rare languages.
  63.  
  64. Regards,    Martin.